Jason Knight  0:00  
Hello and welcome to the show and an episode where we investigate what happens when you have to add to break up, split or combine your cross functional teams. Speaking of adding to your teams, this episode is sponsored by product people. So get this. If you're a company founder or product leader who needs to get a product management team up and running quickly or cover parental leave, why not check out product people. They've got a thriving community and 40 in house product managers, product ops, pros and product leaders. They onboard fast align teams and deliver outcomes. You can check out one night in product.com/product people to book a free intro chat and quote code Okay, to get a 5% discount. That's one night in product.com/product people. You can check the show notes for more details. All right back to the episode. Now. Elon Musk's takeover of Twitter has given us all a cautionary tale about the perils of just trampling over employees, treating them like numbers on a spreadsheet again, all wrong from a people perspective. But if you want to find out about a more human approach to all this stuff, stick with us on what's important.

Jason Knight  1:09  
So my guest tonight is Heidi Helfand. Heidi is a former Rambo knife seller, engineering leader, consultant, coach, speaker and author says that we need to make the most of the time we have with people. She's obviously not met some of the people I've met. Heidi says she likes to go for walks to clear her head and solve problems. She's obviously went for a very long walk to solve one of the biggest problems that companies have how to manage the evolution of teams and indeed the entire organization's and she's walked it twice that she's released two editions of a book dynamic reteaming the art and wisdom of changing teams, where she reminds us that change is inevitable. And what's important is how we respond to it. Hi, Heidi, how are you tonight?

Heidi Helfand  1:44  
I'm fine. Thank you. How are you doing? Jason?

Jason Knight  1:46  
I am doing wonderfully. Well, thank you very much. I'm looking forward to getting to the bottom of some of this difficult team stuff. Me too. But first things first, I was interested to see a foreword from John Cutler in the book, former podcast guest, obviously a big figure in the product community. Everyone loves him. But he said that you encouraged him to start speaking and writing, which is a bold claim. And I do have to ask all you to thank for giving us John Cutler.

Heidi Helfand  2:16  
I thank the universe in the world for giving us John Cutler, more human being I take no credit for all the things that he manages to get out there and do in the world. I'm just glad he's out there in unleashed and able to be creative and share his ideas.

Jason Knight  2:33  
There you go. Yeah, I did say recently that if John Cutler didn't exist, we'd have to create him. But let's talk about the book in a minute and some of the important topics inside. But before that, you are currently consulting and coaching with your own consulting coaching agency. Yes. So what is it that you are actually doing these days? And what types of companies are you doing it with?

Heidi Helfand  2:56  
Yeah, well, I am just signing on with a very small startup to help them be more effective. And yeah, coach people in teams, how they work together, how they break down their work, how they estimate and forecast their work. Are they building the right thing for their customers wide variety of product development and other sorts of coaching as someone that's been at multiple startups for the past 20 years, but you know, a lot of it is about people in teams.

Jason Knight  3:29  
So you say a lot of it, but there's obviously then other stuff as well. So would you say that it very much depends on the types of companies and the problems that they're having? Or do you try and guide them towards, for example, some of the areas from the book that you've written, maybe could be considered your specialty?

Heidi Helfand  3:42  
I don't necessarily go towards the book, deliberately, I think things might come up, depending on the types of problems that we're facing. I generally look to the areas of people issues, like, are we aligned on how we're proceeding forward? Do we have matched expectations? Do we have agreements and how we're going to work together? So people issues conflict, helping people get through that? And then work? Okay, so it's like people work workflow code. So people stuff, work stuff? How are we organising our work? How are we articulating what we're going to work on? Do we have acceptance criterias I like to coach teams and how to break down their work. So people work workflow, I usually coach Kanban type methods, where we're looking at cycle time, we're trying to forecast out when work is going to be done, based on past work that we've done people work workflow, and then code related things I usually partner and bring other people in for challenges. They're like, for example, if teams are having issues with legacy code bases or or how they're coding or those specifics, I don't get into that. But that's where I refer and bring in friends.

Jason Knight  5:04  
That's always good to see someone flying the flag for something that's not scrum as well, which is, you know, nice. I think too many teams just almost default to this scrum methodology or whatever they call Scrum, whatever they've turned it into. So I think it's good to kind of go back to basics in a way and actually just concentrate on the flow of work. So I think that's a really good thing to say, is that something that you kind of strive for across all of this stuff? Or do you sometimes get dragged into more framework battles?

Heidi Helfand  5:30  
I usually stay out of any kind of framework battles and think you can look at this stuff through the lens of different frameworks. But really, it's what's in your toolkit, and what do you want to pull out depending on the challenges that you face? And just after so many years, I think a lot of the coaching is kind of intuitive. And helping people solve problems and I'm not married to anyone framework. I like certain things from Scrum. I like certain things from Kanban. I like, you know, just base the basics of product development, pragmatic product development, what are we going to build? How are we going to break down the work, lightweight documentation, but most importantly, like different levels of defining done so like acceptance criteria for story? Oh, that story is kind of big. Let's break it down. Yep. And there's a variety of methods that I teach with that. I love story mapping. Jeff Patton's work, that's the one book on my bookcase that I bought, like six copies of, yeah, use your story mapping. Yeah, I, you know, I mailed the extra copies that I have people, it's one of the I think, most useful books I've read, ever, I love that book.

Jason Knight  6:41  
That's a very good book. And I really love doing those exercises as well with the team and trying to get everyone together and can be really helpful to generate new ideas and really sort of focus on what's important. But you've kind of touched it, then you've had a bunch of leadership roles across the last few years around engineering, I know you've done agile coaching, had a spell as a project management lead companies back in the past as well. So you've obviously had a very successful career as a practitioner. And I'm sure that you've seen a lot of problems across the years, some of which you talked about in your book, and some of which are coaching in general. But what was it that at some point, whenever version, one of this book came out, that made you sit there and think, Hey, I'm gonna write a book about this stuff, and try and take that out to the world? Was that like a culmination of a number of things that you just said in your career? Or was that like a very intentional plan?

Heidi Helfand  7:31  
You know, it's interesting, because I got this wild idea, I got this itch that I just got became obsessed with that a lot of the books that I would read in order to solve problems as a practitioner, the themes in the books about teams from a variety of disciplines would always say, the goal is get people together, keep them together, have time pass, forming, storming, norming, performing, whatever, you know, that kind of stuff. And then you'll achieve high performance. And I looked back on my career in which I was in teams that doubled, tripled, quadrupled, went from 10 to 600 people. And the constant was shifting and changing and morphing. And we weren't doing it wrong. I that company where I was the 10th employee went public in June 2015. At folio software as a service where I worked with John Cutler for a number of years there, we were at a very successful company. And that kind of static notion of teams was far from the truth. And I wrote the book, because I became very motivated to prove the point that team Change is inevitable, you might as well lean into it and get better at it. Because we're going to be building products, we're going to be doing all the stuff that we're trying to do best, right and make the customers happy. But at the same time, it's like a fun house floor. And a carnival stuff is going to shift and change around us. So there's the discipline of building software, building products, but then there's also the discipline of can you keep your cool when things are going to change on you? Can you do that, like there's a lot of skills related to self management, to adapting to change that's forced on you because it will be I hate to say it, but it's just the nature of it. And then other times depending on your position and influence you're going to want to encourage others to change or influence some changes. So there's those two things I'm so I became obsessed with the topic. I interviewed people around the world and then wrote up the ideas kind of a bottoms up analysis, five patterns of basically base patterns of how teams change. So it's really to prove a point that changes a thing. And a lot of people can relate to it. So that's the reason I wrote the book.

Jason Knight  9:55  
Yeah, I mean, that makes a lot of sense and it feels really natural to again with the The experience you've had and like you say, then the people that you've spoken to, to then try and bring that all into a volume that you can then get other people to think differently about as well. But if we were to look, I mean, you've obviously just given a very good summary of what the motivations for the book were. But if you had to summarise the book in a sentence or two, to someone that was considering whether to buy it, someone listening to this may be thinking, hey, yeah, some of that stuff. Sounds interesting. Maybe I'll buy that book. And they can't be bothered to look at Amazon for some reason. Why should they buy the book,

Heidi Helfand  10:33  
I think if someone is getting started in tech, and wants to know what it's like to work in a fast changing software company, this book paints a picture of what it might be like and the types of changes to expect, because you won't necessarily get that in your school or training. So for the new person to tech, whether you're a product manager, a designer, software engineer, project manager, etc, I think it gives a good idea of what the software industry is like, if you're a manager of any kind. And you're responsible for Team health. There's some activities in here that you can do with teams after they have changed, like to launch their teams, in terms of the people the work the workflow. So I think there's some practical ideas in there. And then for people who drive large scale changes, and want to do that by including people in decision making, there's some guidelines for going through large scale reteaming. Maybe it's 50 or more people, they're essentially reorg. So this book is essentially about reordering. Yeah, there's some guidelines in there about how to try to do it by putting the people first. So it's about that primarily about the people there.

Jason Knight  11:53  
That's very interesting. And we'll talk about some of the specifics in a minute. But one other book that I think of when I'm thinking about teams for tech organisations is Team topologies. And I know that I think Manuel did a bit of a recommendation at the front of the book for you as well. So obviously, he's read it, or I hope he has anyway. But the question, I guess there is whether your book is kind of complementary to that, or whether it kind of replaces some of it, or whether the two books are somewhat separate. And it doesn't really matter how you set your teams up, as long as you kind of work out the right way to do it. Like, how complementary is your book to that book?

Heidi Helfand  12:28  
So I love the book team topologies. I know the author's and we've talked about what is the relationship between dynamic reteaming and team topologies. So I view team topologies is very helpful solution that a lot of companies have chosen to adopt for how they want to organise their teams. And there's different types of teams, right? Streamline teams, platform teams, complicated subsystem teams, enabling teams, etc. And so it's like a specific solution. So if you have a company that wants to shift over, they look at their current teams, they want to shift over to that other structure, you can apply some content from Dynamic retaining. To do that, for example, maybe you want to split a team, the grown split pattern, maybe you have a team and you want to split it in two, and one becomes one of these enabling teams and the other one becomes a platform team. Or maybe it was before, but you split them. So you can evolve your teams over using some of the ideas from dynamic array teaming. You can create an isolated team that works on something, you can merge two teams together. And maybe they become one of the complicated subsystem teams. So the five patterns of reteaming give some ideas for how you might evolve or shift your org over to a new solution. And maybe that's the team topology solution. Or maybe it's something else, I think there's a lot that definitely resonate with people about team topologies. Even the vocabulary is very, very helpful. Like the last company I was at, for example, after being exposed to Team topologies, I had spread it around the world that I was at, we would use the vernacular of enabling teams to describe some of the teams that helped other teams succeed. So team topologies are viewed as a specific solution, a lot of great ideas that resonate with many people. If you want to know how to evolve your org over to it. There are some ideas from Dynamic red teaming, that can help. One more thing. So let's say you do that and you you evolve over to Team topologies using some dynamic red teaming techniques. After you've gotten people into those new teams. You can do some of the activities from my book to kind of kick start the team's like there's activities about you know, chartering your future team, etc. Getting to know the people on the teams. So there's a lot of people practices that go really well with with their materials. So

Jason Knight  15:05  
Oh, wow, there you go. So it's complimentary. But also you should get your book, even if you're using other methodologies because ultimately you're going to be able to help with the people, whatever the teams are, just get. But should people who bought the first edition of your book by the second edition, or is it more of an iteration rather than a replacement,

Heidi Helfand  15:24  
I prefer the second edition. And it I view it as a replacement for the first edition there are there's additional material in here that's not present in the first edition. Namely, a lot of those activities that you can do, when your teams are reset, or when your teams are new. It's chapter 13. There's a chapter on transitions and team calibrations. I wrote that chapter because I was working inside a company that was growing like crazy, doubling, tripling in size. And I wanted to, I wanted to enable engineering managers, product managers, all kinds of people who were caring about the new future of their teams, I wanted to give them recipes that they could use to launch their teams. And so that's why I wrote that chapter, to kind of scale, the coaching I was doing at the time. So that's not in the first edition. And I think that just the fact that so I wrote the book, I self published it on lean pub, the first edition. And it was it was quite a journey. It was fascinating and interesting. And then O'Reilly became interested in it. And then we decided to do a second edition together. And it's really nice to have a thought partner, I had a wonderful developmental editor that I worked with, that really helped me just make the book better quality site. I think it's a it's a better result. So yeah, you

Jason Knight  16:54  
get double money for that one.

Heidi Helfand  16:56  
And props to Melissa Potter from O'Reilly, she was an incredible editor partner that I worked with.

Jason Knight  17:03  
Oh, there you go. The two of you made a team of your own. But let's talk about teams. Yeah. So obviously, we talked about team topologies. We talked about there's probably other ways to manage teams. And there's definitely other ways to manage teams. But in your own words, how do you define a team? Like is it a functional group, like a bunch of developers working on a project? Or is it a cross functional team aligned around a mission around a value stream? Both of those something else, something more broad? Like what is a team for you?

Heidi Helfand  17:30  
A team for me is two or more people who are thought partners working on a joint project, Melissa Potter and I were a team when developing the second edition of dynamic red teaming. I think in English, the word team can be ambiguous. Maybe a group of people that really aren't working on the same thing can be referred to as a team, very large companies can be referred to as a team. That's a word that has many different meanings. Typically, the teams that I work with out in the wild at different software companies are cross functional teams, with engineers, designers, product managers, maybe some quality assurance folks as well. And they're working together on like shared goals, shared work.

Jason Knight  18:19  
So then, does that imply that this is really a book that's aimed at tech teams? Or do you think that people working in non tech, maybe traditional industries, traditional types of companies could also benefit from some of the practices within your book,

Heidi Helfand  18:34  
this book is aimed at tech teams. And that was a very deliberate decision, I had considered writing it in a more general way for like any team. However, that just wasn't as interesting to me, I thought it would water down some of the concepts, I thought it would make it just less specific. So this is written definitely for the tech crowd. I think there's some activities in here that other teams might find interesting, but it that would just be a bonus.

Jason Knight  19:03  
Well, they should buy it anyway. Right. But if they want to, but there's a lot of chatter out there. And you call this out in the book as well about the benefits of stable, long lived teams, empowered and self organising missionaries, over mercenaries, all of that good stuff. And that's obviously a bit of a trope. Now in the product development world. It's something that will almost taught to do or taught to think like, we just want to keep the teams together, keep them as stable as possible. And not just to kind of keep moving them around or breaking them up or anything like that. And I know that you're not advocating just breaking teams up for the sake of it, but at the same time, do you think that there's anything to this kind of stable, long lived team self organising team or is there a lot more to love in this idea that you should be constantly looking at the makeup of your teams, and effectively moving people or encouraging people to move around when the need arises?

Heidi Helfand  19:57  
I think the reality of the situation addition is that, even if we want the team to stay together stay the same. There are forces that always pull us apart, they could be an individual's preference and working on something else, maybe they get burnt out after being with the same team for two months, and they just want a change of scenery or to work with another person. Yeah, I think there's always forces that are pulling us apart. That's why if you are in a team situation, and it's incredible, you feel like you're delivering amazing things to your customers at a great cadence, you're learning, it's enjoyable, there's that chemistry going on, you want to try to keep it together, but it's not always possible. And I think that's the, I sometimes when I give a talk, I have an ice cream cone that's melting, you know, sometimes you when you have a great team situation, it's something to really be appreciated and honoured and to be grateful for because it won't be forever. And I think there's a lot of, you know, it brings some sadness for me, because I always, you know, I want people to be happy, I want them to have a great situation, be motivated. These are our lives. And sometimes we have these amazing experiences together, but they are ephemeral. And so, so yeah, I just just think it's inevitable that it's not going to last. So let's enjoy it while we have it. Sometimes, even if a team is together for a long time, maybe it's not enjoyable. And then I would kind of, you know, question whether you want to stay with that team, if if you're feeling not happy or negative in any way, you know, just the fact of people together for a period of time doesn't necessarily mean that it's a good thing.

Jason Knight  21:58  
No, absolutely. I think the ephemerality, if that's even a word is something that we should just own and make sure that we stay on top of. And, again, as we kind of said, like, just make sure that we're always revisiting and reviewing to make sure that we are actually working on the most important things and that we're setting ourselves up to work on the most important things. But when we're talking about reteaming, some companies might sit there and almost approach to this and are very Zeus from Clash of the Titans, moving all the pieces around on the chessboard, putting people in different places and just kind of manipulating them into where they want. Now, I'm going to assume that's not what you're talking about in this book. But is there any case for more of a top down dictatorial team reorganisation? Or should it always be self generated from within the teams themselves,

Heidi Helfand  22:47  
you're gonna have all types of changes. And people don't always get to decide or have input into what these changes are. If you're in a company, and they're acquiring another company, and the people are getting blended together into the teams, maybe you have a chance to give input or maybe not, it's just a fact of nature, that you're going to have some changes coming from your executive team, you're going to have some changes coming from within your team, some changes coming from your department level, all types of changes. It's just how it is. I'm not judging whether it's bad to have them come from the outside or whether it's bad that your executive team is making these decisions. Sometimes it's the health of your company is at risk. I was at a startup, the first startup I was at, we were going to change the world. We were building an online marketplace for tech support. You were supposed to come to the website, enter a tech support problem. And then you connect, we connect to you see and control your computer to solve the problem. I was on a web development team. At the time I wasn't a writer, I became an interaction designer. We had hopes and dreams for this. The problem was nobody was buying the product the company was going to go under if we continued working on this marketplace for expert tech support, and a reorg happened. I was able to be part of a team that was moved to this side, given process freedom, we were able to work on something brand new. I didn't have input into this decision. I was glad to be invited to be part of this team. Some of us were just isolated. It's like the isolation pattern in my book was inspired by the story. Yeah, as part of this isolated team. We were able to pivot it was a pivot that I believe saved this startup. We worked on a product called we later named it go to my PC. And then we invented later Go To Meeting Go To Webinar back when we were integrated back into the company, but kept down change that we had no, it wasn't like there was a vote or something thing you don't always get to decide. But what you do get to decide is how you respond to the changes that are going to happen. And I think that is part of the work in leading yourself through dynamic reteaming, or leading yourself through reorg is stuff is going to change, you're not always going to like it, sometimes you're gonna love it. And you get to decide how you steer your own personal ship, and how you behave in response to that. And leaders have a big responsibility for how they want to be in it to a lot of leaders are talking about changes for months, especially if they're large, wide changes, just because you were talking about it for months, the minute that you introduce it to all of the people, it's brand new for them, they haven't been talking about it for months. So leaders need to have patience to, you know, when they're unrolling or when they're, they're rolling out any kind of larger scale change. And I think it takes some empathy. I think it takes a lot of patience, as I was saying. And it means you need to be redundant, as well, as you're communicating what the changes are. So there's some of that in this book. There's some new ideas I'm developing around A Leaders Guide to dynamic reteaming, because I just spent a year as part of an executive team. And I learned a lot there with about, you know, the perspective of team changes from from that seat. This book I dynamic reteaming, I wrote from a coach's vantage point, yep. But now I have some some more sort of, in the trenches experience as part of an executive team.

Jason Knight  26:39  
Well, there you go, you've been in the top down position. But at the same time, there's a lot of stories you hear around places like Google, where, as far as I'm aware, they can kind of just pick whatever teams, they want to work on themselves, right. And obviously, Google has made quite a success of that. But then, at times, maybe slightly less successful, depending on which bit of product that you're talking about on any particular day. And I did read an article about how it also leads to some really bad behaviours. Like, for example, people are getting rewarded for getting something launched. So they go and work on a new team to get something launched, then immediately leave that team and go and join a different team to learn something else, because that's what they get rewarded for. So I guess the question is whether there's always a need for some level of oversight, or if there are any situations where an actual free flow would actually be better, or could deliver benefits that you couldn't get from a top down organisation.

Heidi Helfand  27:31  
I think your your mileage may vary in the people that are involved in executing and participating in any of these changes, whether they're bottoms up, driven, changes top down, or somewhere in between. Yeah, there's that Hunter Industries, suffer sprinkler company in Southern California, they practice a lot of mob programming, maybe you've talked to some of the team members in the past, there's a story in my book, I interviewed Chris Lucien, who's their head of engineering, and was telling me that the people reteam there, the engineers are able to decide when they move to another team, they work it out with each other. And after they've worked that out, then they tell the management. And I thought that was kind of an interesting story, because it was like, Well, who gets to decide on these changes? I think sometimes in companies, maybe someone has an idea to start a new team, if they have influence, and they're able to persuade their management that they should have a team working on something. And here are the benefits, they might get to do that. I've experienced that personally with teams that wanted to form to develop front end design patterns, to create like a pattern library that can be shared across different teams to solve problems of, you know, creating two different date pickers, or more. So they have a shared library of resources. I've seen it when people catalyse teams that way, I always really liked that idea of, you know, whether it's a team change, working on a new technology, something else, maybe a process change, people, bringing them up and just trying to influence others. And it's a skill to learn. This is the impact I want to make. These are the outcomes to get to the impact. Who's going to work with me, you know, part of being at work is coming up with ideas and trying to get them put in place.

Jason Knight  29:26  
No, absolutely. I mean, I'm a big fan of bottom up organisation within teams and bottom up innovation as well. I think it's important to realise that the best ideas don't always come from the top. But I think like what you say, really makes a lot of sense around the idea that it's kind of you don't just get to do it, you kind of have to persuade them that it's a good idea. And that's where the generation comes from, rather than just just walking around into random rooms working on different stuff on a week by week basis.

Heidi Helfand  29:53  
Yeah, you always need to have executive alignment for what you're doing. I was at a company a couple Companies ago, and I was working with a front end architect, and we were spreading some lean Kanban practices, we, we spread them to about 25 teams. But we didn't work hard enough to get executive buy into what we were doing. We did go vertical enough. Yeah. And, you know, ultimately, I think a lot of it faded away. Because we didn't have that alignment. I think there's, you know, we can do grassroots things. But I think if we want to try to sustain things, we definitely need executive input and participation. I learned that the hard way.

Jason Knight  30:41  
So the book lists five different ways you can meet him. And we're not going to go into them in excruciating detail, because we want people to go and buy that book. But if we could do a bit of a quick fire round here to describe a little bit about each of the five ways, and one question about each one, just to kind of give a little bit of a flavour and some of the things that might come up. So the first one, and you touched on this earlier is this kind of one by one pattern where you're bringing a new person into the team, one person at a time. Now, that can obviously be really daunting. But how can we make that work best and make sure that the new person in the team is actually super effective and feels like part of the team as soon as possible?

Heidi Helfand  31:21  
Focusing on belonging is one thing you can do with the one by one pattern, how do you behave so that a new team member feels like they belong? Yeah, there are things you can do in meetings, just asking someone's thoughts and opinions, showing that you're listening to them, asking them about themselves. So focusing on having that person feel like they're part of the team is really key.

Jason Knight  31:51  
Absolutely, so about getting people to feel like part of the mission and make sure that they're not just seen as this outsider. Yeah. So then the next one is grow and split. So your team's gotten too big. We can't order enough pieces to feed them anymore. We've got to break up the band. So what are some of the watch outs there when you're breaking up one team into say, two teams, and how to do that effectively without kind of ruining morale or putting all the wrong people in one team or basically doing it in a really inefficient way.

Heidi Helfand  32:22  
So ideally, it's the team's idea that they feel like they'll be more effective if they split into two or three teams. And what holds people back when they do this is not being organised around it. It's nice to have a timeline of when you're going to split. Understand the impacts to all the different roles. Is anyone can be really shared between the two teams. After the split, you can't just poof, here's another product manager. Is this team split mean that the product manager is going to oversee two teams now there could be hiring implications. Yeah, so you have to organise the split. Think for different cases, even just how are we going to organise our work are we going to likely you'll have a different board and whatever tool you use to manage the work. So there's a lot of details like that. But if it's someone from the outside splitting the team, and the team doesn't like the idea, you're not going to have a good experience. Ideally, this is coming from the teams and it's also connected to high growth situations, you'll have a lot of growing and splitting. If your team is doubling or tripling in size, just kind of what happens.

Jason Knight  33:39  
Now, I guess kind of by default, that's going to happen. Right? So the third one, we're gonna go a bit Tom Hanks in Castaway now and talk all about isolation. So we're setting up an entirely new firewall team within a business. What are some of the situations you'd want to do that and

Heidi Helfand  33:55  
sometimes for solving emergencies, you want a team to be undisturbed and isolated. Maybe there's an production incident. I was with the team once we were releasing our first product, but it had a lot of performance issues. They put themselves in a conference room for weeks and weeks brought in a consultancy even and solve the performance issues and went back to the other team. Sometimes these are short lived teams. Sometimes when you want to start a new product, and you already have an existing product, it helps to have an isolated team working like a startup within your company.

Jason Knight  34:33  
Is there a risk that people start to get a bit jealous of that team working a lot of cool stuff?

Heidi Helfand  34:39  
Could be Yeah, human nature. People might have FOMO but you can't have ever everybody can't do everything. And yeah, it's it's definitely something that can happen.

Jason Knight  34:55  
Fair enough. Well, buy him some more swag or something just to keep them on side. Yeah, but now on to merging teams. So we've got two teams presumably working on quite similar stuff. Or maybe we've just acquired another company. And we've got to smush all of our people together into one team. Now that obviously could go wrong in a number of ways. So how can we make sure that when we do smoosh those people together and make one nice new team to work on all the cool stuff they're going to work on, that are actually working as a team and not too independently.

Heidi Helfand  35:24  
One activity in my book is called story of our team. And I like to do this with teams that merge together, basically, they create a timeline on the wall. And really, if you think of two teams merging together, it's like two branches coming together. And we write on the timeline, we stand up, or we align ourselves in order of when we join the team. And we make a timeline of all the significant milestones and achievements that we've had as a team. And so we get to know the history of the other team, and we get to share our history, and then we get to come together and vision out our future. That's an activity that I really like to do. I think it raises positivity, and it enables us to share our accomplishments that we've had as our individual teams together to kind of aid in the forming of the identity of the new team. That's something that is in the book that that people have found useful. Yeah, just like when splitting teams or when merging teams, it's helpful to have a timeline. There's in chapter, I think it's chapter 13, or no chapter 12 of my book, it's called plan your dynamic retaining initiative. It has some guidelines in there about creating a one pager around team change you're going to have whether it's merging or splitting or something else. Yeah. And basically, you identify like, this is the problem I'm trying to solve with this change. This is what the teams looks like before the change. This is what the teams look like after the change. And then you start writing an FAQ or frequently asked questions, Doc, about the change, you include a timeline, it pretty much takes you step by step about how to go about these types of changes. So it's helpful for multiple patterns in the book, but in particular, growing split, and also merging. And I will say that more teams merge, when a lot of people are leaving your company also. Yeah, if people might have experienced this in the past year, or the past two years, where we've had a lot of departures from teams for a variety of reasons, we might find that we have more situations in which teams are condensing or merging together. It's just what happens.

Jason Knight  37:44  
Yeah, no, absolutely. And I guess that's a really valid point, like sometimes you're going to your team is just going to start to become unsustainably small, as as when you say when either people will leave naturally, or when you have to maybe downsize because of as you've kind of touched on pandemic and all the uncertainty through that. So I guess just being able to manage that really, effectively, make sure that you come out of the back of it with some level of sanity, and not just kind of just a big mess, which obviously can happen. Yeah. But finally, we want to switch in teams. So now I'm starting to think that we're trading people like fantasy football or some other game like that. And I'm assuming that's going to share some characteristics with the one by one pattern, depending on how many people you're switching. But are there any specific watch outs there when you're effectively moving people between teams for the greater good?

Heidi Helfand  38:38  
Yeah, some things to watch out for are in I talk to software engineers all the time and encourage them to pair or work in groups. So they develop some kind of redundancy. Sometimes it's hard to switch to another team if you're the only one that knows how to work on that particular system. So we always want to work in such a way that we can obsolete ourselves from a team, because we might get bored with that initial subject matter and want to work on something else. Yeah, the switching pattern is really about the pursuit of fulfilment, and being able to move towards the work that's more interesting or the people that might be seem more interesting to work with. So there's that. There's also some stories in the book about companies that deliberately have a practice of switching people from one team to the next. Yeah, with the idea of knowledge spread. And with a lot of these, I think, you know, you're going to get into it when you join the company. Maybe they pair and they switch pairs as a deliberate way to build more resilience and knowledge retention in the company. Their stories in here from Menlo innovations, from Ann Arbour Michigan about how they parents switch pairs. So switching is about fulfilment. It's about proactively trying to keep no In the building, ideally you have parity with your hiring practices so people know what they're getting into. And they're joining if you do things like this, because they're not that common, there are some companies. There's great Chris Smith from Red Gate software in Cambridge, UK, they have an annual event that he writes about quite prolifically online. And they reteaming at Red Gate software. And every year they have a deliberate kind of switching event. I think that's really cool. It's worked for them. He collects statistics about that. I'm going to see him I'm going to Sweden in a couple of weeks. And he is as well for conference or Dev. And looking forward to catching up with him about that there's a case study about them in dynamic reteaming as well. Yeah, yeah. There's no one size fits all to this stuff. You know, it's like, companies are different. They develop ways of working. And some of them are more dynamic than others. It's not that one's better than another. They're just things are just different.

Jason Knight  41:10  
Absolutely, it depends, which is the product managers mantra. But is there any? I mean, I'm sure there are many. But is there one very specific top contender for thing that people shouldn't do when they're going through any kind of reteaming exercise dynamic or otherwise?

Heidi Helfand  41:28  
Is there one thing that people shouldn't do? Well, I think people have different intentions, there's always impact to the choices that we make. I think people are always more successful when they get input on changes. It doesn't mean everyone has to decide what the changes are. If you're clear on decision making, there are some decision making frameworks that I prefer, I think things tend to go better. If you're really kind of moving people around a lot. You're probably going to have some issues, especially if you're not communicating the why of it. Yeah, this stuff is hard. It's easy to make mistakes. I have made plenty of mistakes with reteaming dynamic reteaming. In my career, I can always hope to get better, I think, yeah, people just need to try to be kind to each other. Get input. These are our lives, we want to treat each other with respect. The best we can. Don't be, you know, don't be mean to people. I don't know, that sounds so trite, but try to come with kindness. But still, no matter what you do, it's always possible that someone's going to be upset because they liked it the way it was. Yeah. But now you're introducing a change the say if you deliberately make a change, sometimes forces of nature are going to come upon us and it's going to cause changes in our teams. COVID Suddenly, we get this, you know, big horrific curveball that impacts our teams. It's not necessarily something that anybody wanted. So yeah, try to be kind.

Jason Knight  43:19  
Be nice. Don't be a douche and try and look after everyone as best you can. Well, that's obviously Aston advice not just for dynamic reteaming, but for life in general. And I'm hoping everyone's feeling inspired to be a bit kind of doing their next reteaming exercise. But where can people find you after this? If they want to find out more about reteaming about your book about navigating change? Or see if I can still tap you up for a Rambo knife?

Heidi Helfand  43:45  
Yeah, you can find me on LinkedIn, Heidi Hill fan, you can go to Heidi Hill fan.com. All these ways. Yeah. I no longer sell Rambo knives. But that was part of my early career at the night. You still have any? I did not sadly, I never bought one myself. I just showed Rambo knives to people that wanted to buy them.

Jason Knight  44:08  
That's one way to motivate people. Yeah, well, I'll make sure to link that all into the shownotes. And hopefully, you'll get a few dynamic people heading in your direction. But it's been a fantastic chat. So obviously really glad you could spare the time to talk about some important and complicated organisational issues and how we might all be a little bit nicer to each other. Hopefully, we can stay in touch. But as for now, thanks for taking the time.

Heidi Helfand  44:28  
Thanks, Jason. I enjoyed our conversation.

Jason Knight  44:33  
As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to hop over to white knight in product.com. Check out some of my other fantastic guests, sign up to the mailing list or subscribe on your favourite podcast app and make sure you share with your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest but as for now, thanks and good night.